1. Field of the Invention
The present invention relates to the field of data entry and retrieval and, more particularly, to a method and system for associating annotations with entities associated with a data object related to the annotation.
2. Description of the Related Art
There are well known methods for capturing and storing explicit knowledge as data, for example, in relational databases, documents, flat files, and various proprietary formats in binary files. Often, such data is analyzed by various parties (e.g., experts, technicians, managers, etc.), resulting in rich interpretive information, commonly referred to as tacit knowledge. However, such tacit knowledge is often only temporarily captured, for example, as cryptic notes in a lab notebook, discussions/conversations, presentations, instant messaging exchanges, e-mails and the like. Because this tacit knowledge is typically not captured in the application environment in which the related data is viewed and analyzed, it is often lost.
One approach to more permanently capture tacit knowledge is to create annotations containing descriptive information about data objects. Virtually any identifiable type of object may be annotated, such as a matrix of data (e.g., a spreadsheet or database table), a text document, or an image. Further, subportions of objects (sub-objects) may be annotated, such as a cell, row, or column in a database table or a section, paragraph, or word in a text document. An indexing scheme is typically used to map each annotation to the annotated data object or sub-object, based on identifying information, typically in the form of an index. The index should provide enough specificity to allow the indexing scheme to locate the annotated data object (or sub-object). Further, to be effective, the indexing scheme should work both ways: given an index, the indexing scheme must be able to locate the annotated data object and, given an object, the indexing scheme must be able to calculate the index for use in classification, comparison, and searching (e.g., to search for annotations for a given data object).
In many situations, portions of a collection of data, such as database rows, are roughly analogous to ‘entities’ or objects. As an example, a table with patient records may have a primary key which is a patient number (patient ID) and would likely also have a patient name (first and last), address, preferences, and the like. All the other information for a particular row may be regarded as being related to a ‘patient entity’ uniquely identified by the patient ID. Similarly, all the information for a particular row of information in a table of test results may be regarded as being related to a ‘test result entity.’ Some information may be related to more than one entity. For example, a patient's test results may be related to both patient and test results entities. Further, information related to a single entity may be contained in multiple tables. For example, demographic information related to a patient entity may be contained in a table of patient records, while test results for the same patient entity may be contained in a table of test results.
One potential problem, however, presented when capturing and sharing information in an annotation, is selecting the proper scope of an annotation describing data related to an entity. The problem may be described with reference to the table of exemplary query results (listing patient test results) shown in Table I below.
TABLE IExemplary query resultsPatient NameTest NameTest ResultTest DateJohn DoeHemoglobin12Jan. 24, 2003Jane SmithHemoglobin22Feb. 25, 2003The test results for the second patient (Jane Smith) may be invalid, for example, because the patient forgot to fast before the test, possibly skewing the results. Accordingly, a user (e.g., a lab technician) may wish to create an annotation describing this situation and suggesting the test be re-run, for example, during the patient's next scheduled visit.
While there are several locations from which the user may choose to specify the annotation, none of these may be ideal to accomplish the desired result (make someone aware the patient should be retested). For example, the user may choose to associate the annotation with the row. However, this may not be ideal, as the information may span multiple tables (e.g., patient records and test results). Similarly, associating the annotation with the entire table of results is not appropriate, as the annotation concerns the test results for only one patient. Associating the annotation with the name column clearly is inappropriate, as the annotation is not applicable to the first patient (John Doe), whose test results are fine. However, associating the annotation with the particular name cell (Jane Smith) may not be ideal either, as many queries may not include name information (which may not be unique, as multiple patients may have the same name), preferring unique identifiers, such as a patient ID. While associating the annotation with the patient ID may be a logical choice, patient IDs are not available in the query results in TABLE I. In fact, in many cases, for security reasons, certain users may be prohibited from viewing any type of identifying information (e.g., patient IDs and names).
Accordingly, there is a need for methods and systems allowing a user to associate an annotation with an entity, regardless of whether information uniquely identifying the entity (e.g., a primary key) is displayed in query results. Preferably, the methods and systems will allow subsequent users viewing information related to the same entity to view the annotation, regardless of whether they are viewing the particular information described by the annotation.